SWITCH NAME, IP ADDRESS, AND HARDWARE SERIAL NUMBER 
AS PART OF THE TOPOLOGY DATABASE 

FIELD OF THE INVENTION 

The present invention is related to network management 
5 with the use of a topology database. More specifically, the 
present invention is related to network management with the use of 
a topology database having configuration information. 

]\2 BACKGROUND OF THE INVENTION 

Network management can be simplified by having all 
network configuration information accessible from a single 
location. Current implementations do not provide any such 
repository for several types of important data, such as switch name 
\i or switch IP address. An administrator, or automated 

i2 administrative data collection task, is therefore required to 
establish a connection with each individual switch to query for the 
information. In large networks, this quickly becomes a cumbersome 
procedure . 

Information stored in the Topology Database (TDB) is 
shared between all switches in a PNNI peer group (a logical 
20 collection of switches) , Therefore, if switches place their 
configuration information in the TDB, all other switches in the 
PNNI peer group will have access to it as well. The network 
administrator will then be able to retrieve the relevant data for 
all of the switches in the peer group from a single location. 
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SUMMARY OF THE INVENTION 

The present invention pertains to a switch of a network. 
The switch comprises a topology database having configuration 
information. The switch comprises a mechanism for sending the 
5 configuration information from the topology database to the network 
and for receiving configuration information from the network and 
storing it in the topology database. 

The present invention pertains to a telecommunications 
'^f system. The system comprises S switches, where S is an integer 
%h greater than or equal to 2 . Each switch has a topology data base 
with all configuration information of the S switches, any one 
switch providing all the configuration information for all of the 
U S switches. 

The present invention pertains to a method for operating 
15 a telecommunications network. The method comprises the steps of 
placing configuration information of a first switch of the network 
into a topology database of the first switch. Then there is the 
step of propagating the configuration information of the first 
switch to a second switch of the network. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

In the accompanying drawings, the preferred embodiment of 
the invention and preferred methods of practicing the invention are 
illustrated in which: 

5 Figure 1 is a schematic representation of a system of the 

present invention . 

•t jj 

■'i Figure 2 is a schematic representation of a switch of the 

'••F present invention. 

! . J 

% DETAILED DESCRIPTION 

iX) Referring now to the drawings wherein like reference 

numerals refer to similar or identical parts throughout the several 
views, and more specifically to figures 1 and 2 thereof, there is 
shown a switch 10 of a network 12. The switch 10 comprises a 
topology database 14 having configuration information 16. The 

15 switch 10 comprises a mechanism for sending the configuration 
information 16 from the topology database 14 to the network 12 and 
for receiving configuration information 16 from the network 12 and 
storing it in the topology database 14 . 


20 


Preferably, the sending and receiving mechanism 18 
includes a switch agent 20 for receiving configuration information 
16 from the network 12. The switch agent 20 preferably looks up in 
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the topology database 14 and returns requested information of an 
SNMP query from the network 12. Preferably, the switch agent 2 0 
forms an SNMP query to the network 12 . 

The topology database 14 preferably has all configuration 
5 information 16 of the network 12. Preferably, the configuration 
information 16 includes the name 22 of the switch 10. The 
configuration information 16 preferably includes an IP address 24 
of the switch 10. Preferably, the configuration information 16 
''''i includes a software version 26 of the switch 10. The configuration 
iJjD information 16 preferably includes hardware type 28 of the switch 
10. Preferably, the configuration information 16 includes a unique 
'^l ID 30 of the switch 10. The configuration information 16 
preferably includes a remote node index 32 of the switch 10. 
N Preferably, the configuration information 16 includes nodal flags 
p5 34 of the switch 10. The configuration information 16 preferably 
]:j includes an interface name 36 for the address of the switch 10. 

The present invention pertains to a telecommunications 
system 38. The system 38 comprises S switches 10, where S is an 
integer greater than or equal to 2. Each switch 10 has a topology 
2 0 database 14 with all configuration information 16 of the S switches 
10, any one switch 10 providing all the configuration information 
16 for all of the S switches 10. 

Preferably, the switches 10 send configuration 
information 16 to each other. The switches 10 preferably send SNMP 
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queries to each other to return retrieved configuration information 
16 from each other, and the switches 10 respond to the SNMP queries 
by sending the requested configuration information 16 to the other 
switches 10 which sent the SNMP queries. Preferably, the switches 
5 10 attach a systems information group to a nodal information group 
to propagate the configuration information 16 to the other switches 
in response to an SNMP query. 

The switches 10 preferably have one or more logical nodes 
40. Preferably, the nodes 40 form a first PNNI peer group 42. The 
lO) system 38 preferably includes a plurality of PNNI peer groups 44. 

n Preferably, any node of the first PNNI peer group 42 can provide 

j. il 

[■^ all the configuration information 16 for the first PNNI peer group 

The present invention pertains to a method for operating 
i$ a telecommunications network 12. The method comprises the steps of 
placing configuration information 16 of a first switch of the 
network 12 into a topology database 14 of the first switch. Then 
there is the step of propagating the configuration information 16 
of the first switch to a second switch of the network 12 . 

20 Preferably, the first and second switches are in a PNNI 

peer group, and after the propagating step there is the step of 
retrieving configuration information 16 for all the switches in the 
PNNI peer group from the first switch. Before the propagating step 
there is preferably the step of sending an SNMP query from the 
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second switch to the first switch for configuration information 16 
in the topology data base of the first switch. 

Preferably, the propagating step includes the steps of 
attaching a system information group having the configuration 
5 information 16 from the topology data base of the first switch 
requested by the SNMP query to a nodal information group. Then 
there is the step of propagating the system information group 
yvi attached to the nodal information group to the second switch. 

\:} In the operation of the preferred embodiment, all 

16) switches in a network 12 running the PNNI protocol contains one or 
'^l more logical nodes 40. Each node can be considered a. separate 

switching entity. A number of nodes 40 may be contained within a 
rj PNNI peer group, which is a collection of logical nodes 40 that 

maintain identical topology information via the flooding protocol. 

15 The flooding protocol is used to distribute information 

from one switch to the other switches in its PNNI peer group. The 
information is contained in standard formats. These information 
group (IG) formats are specified by the standard, so that switches 
from different vendors can interoperate . 

20 One IG, the System Capabilities IG, is structured to 

allow switches- to store proprietary information within the IG 
without affecting the ability of the switch 10 to interoperate. In 
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addition, these IGs may be attached to any other IG used in the 
protocol . 

All nodes 40 in PNNI must flood a Nodal Information IG, 
which stores required information about a particular logical node. 
5 Thus, all nodes 4 0 in a PNNI peer group will have a Nodal 
Information IG from every other logical node in the same peer 
group . 

'^i By attaching a System Capabilities IG to the Nodal 

Information IG, any information placed in the System Capabilities 

ip IG will be flooded to every other node in the PNNI peer group. 

II Therefore, the desired switch information can be propagated to 
other switches by placing it into a System Capabilities IG attached 

rJ to the Nodal Information IG of all of the logical nodes 40 within 
the switch 10. 

15 One current method to retrieve information from the TDB 

is to perform an SNMP query to the switch 10. The switch agent 20 
receives the SNMP query, and then looks up and returns the 
requested information. The switch agent 20 has direct access to 
the TDB, and can therefore obtain the switch configuration 

2 0 information 16. 

Thus, using SNMP queries to a single switch, a user can 
obtain the configuration information 16 of any switch in the same 
PNNI peer group. Because all nodes 4 0 in a network 12 must have 
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globally unique identifiers, the Node ID's are long and difficult 
to remember. In PNNI, for example, a typical node ID 3 0 is: 

Node: 80:160:47. 0 000 000 00 0aelelelele2 Ode . f f Ia2 0dc0001 . 0 0 

In a default PNNI implementation, there is no further 
5 information available to identify a remote node except for its Node 
ID 30. By flooding the switch configuration information 16 with 
the nodal information, it becomes possible to map the node ID 3 0 to 
a more human friendly form. In particular, the node can be 
: :1 specified by the switch it resides on, and the node index 32 of the 
node on that switch. The previous example could now be listed as: 

Node: lab-switch-20 (2) 

1 : 

i -J 

'■i On-switch configuration menus could use this notation to make node 
□ listing much more informative to the user. 

It should be pointed out that because the PNNI flooding 
15 protocol is used to transmit the information, the extent that 
information can be shared depends on the limitations of the 
protocol. That is, switch configuration information 16 is only 
available for those switches that are known to a switch through 
PNNI topology database 14 exchange. 

20 Using the PNNI topology database 14 to store switch 

configuration information 16 has several advantages. PNNI provides 
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the System Capability Group (IG) as a method to distribute 
proprietary information in a standards-compliant way. Using the 
topology database (TDB) allows switches to leverage the standard 
PNNI flooding protocol to distribute information without the need 
for additional proprietary protocols. 

Switches that include system configuration information 16 
(such as IP addresses) in the system capabilities IG will operate 
seamlessly with switches that do not. If a switch does not 
understand the information, it will pass the IG on to other 
switches that do. Additionally, there are existing procedures in 
place to retrieve information from the TDB, which provides for 
rapid implementation of the invention. 

A network 12 administrator commonly accesses other 
information stored in the TDB. The new switch information can 
therefore be retrieved using an existing and familiar interface. 

Configuration Information Stored in the TDB for Each Remote Switch 

1. Switch software version 

2 . Switch hardware type 

3. Switch Unique ID (usually a hardware serial number) 

4. Remote Node Index (an integer, usually under 10) 

5. FORE Nodal Flags (proprietary routing information) 

6. Switch Name (text, e.g. " labswitch35 " or "asx4000-2" 

7. For each IP address 24 on the switch, the following: 
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- The interface name for the address (e.g. 'ieOM 

- The actual IP address 24 (e.g. 192.34.98.34) 

Abbreviations Used : 

PNNI: Private Network-Network Interface, or 

Private Network Node Interface 

TDB: Topology database 

IG: Information group 

SNMP: Simple network management protocol 

In summary, this system 3 8 provides the desired 
information with no disruption to the network 12, minimal need for 
additional implementation, and no significant modifications to 
existing discovery mechanisms. 

Although the invention has been described in detail in 
the foregoing embodiments for the purpose of illustration, it is to 
be understood that such detail is solely for that purpose and that 
variations can be made therein by those skilled in the art without 
departing from the spirit and scope of the invention except as it 
may be described by the following claims. 


